部分程序员在写代码时，有时会写一些 “经过优化的”的代码，期望可以帮助完成垃圾回收的工作，但实际上，这只是他们的 错觉。记住，过早优化是万恶之源（premature optimization is the root of all evil）。就Java来说，想要控制垃圾回收就更是难上加难，垃圾回收器 "自己知道该怎么做"。
正如在前面的章节中介绍的，System.gc()只是一个提醒，并不能强制发生垃圾回收，因此，不要滥用之。
除了垃圾回收外，对象池（object pool）也是Java中常见的 伪优化（false optimization）。有人认为，重用以创建的对象可以提升垃圾回收的性能，但实际上，这是错误的。对象池不仅加大了应用程序的复杂度，还很容易出错。使用java.lang.ref.Reference系列类实现缓存，或者直接将无用对象的引用置为null就好了，不用多操心。此外，长期持有 已过期的对象其实是个大麻烦，分代式垃圾回收器可以很好的处理临时对象，但如果这些临时对象被人为保存下来，无法被回收掉的话，最终就会被提升到老年代去，并一直存在。
近来，人们认为，应该添加控制Java垃圾回收的空乏，添加free或delete操作符，以及打开关闭垃圾回收的方法，另外，还有想直接访问JVM中本地指针的。不得不说，如果真的在Java中引入了这些 "特性"，对于编写Java程序来说将会是非常危险的，想要用好这些 "特性"实在太难。
自动内存管理有利有弊，其为人诟病的地方主要在于其不确定性，JRockit Real Time试图在不修改应用程序，不操作垃圾回收器的前提下，通过其他的方式来绕过这个问题。
在JavaOne 1999年的会议上，"Java应该有
free操作符"的讨论贯穿整个HotSpot议题。发起这个讨论的哥们还叫嚣"我有很多从事C++开发的朋友......"
事实上，基于现代JVM，如果能够合理利用书本上已有的技巧，例如正确使用java.lang.ref.Reference系列类，小心使用Java的动态特性，完全可以写出运行良好的应用程序的。如果应用程序真的有实时性要求，那么一开始就不该用Java编写，而是使用那些由程序员手动控制内存的静态编程语言来实现。
作为一个强有力的辅助特性，自动内存管理可以缩短开发周期，降低应用程序复杂度，但它并不是 "大力丸"，不能 包治百病。